UNCLASSIFIED 


ni!  FiiF  r,op^ 


AD-A206  147 


DOCUMENTATION  PAGE 


1%*/^  I  HU  I  MWKI  I  Y 


2b.  DECLASSIFICATION /DOWNGRADING  SCHEDULE 


Form  Approved 
0MB  No.  0704-01 aa 


1b.  RESTRICTIVE  MARKINGS 


3.  DISTRIBUTION /AVAILABILITY  OF  REPORT 
Approved  for  Public  release. 
Distribution  unlimited 


4.  PERFORMING  ORGANIZATION  REPORT  NUMBER(S) 

MAG-87-()09-01 


5.  MONITORING  ORGANIZATION  REPORT  NUMBER(S) 

MAG  87-009-01 


6a.  NAME  OF  PERFORMING  ORGANIZATION 

Software  Production  Branch 


6b.  OFFICE  SYMBOL 
(If  applicable) 

WR-ALC/MAITB 


7a.  NAME  OF  MONITORING  ORGANIZATION 

MATE  Application  Group 


6c  ADDRESS  {City.  State,  and  ZIP  Code) 

Robins  AFB  GA  31098-5149 


7b.  ADDRESS  (Ofy,  State,  and  ZIP  Code) 

WR-ALC/MAIT 

Robins  AFB  GA  31098-5149 


8a.  NAME  OF  FUNDING /SPONSORING 
ORGANIZATION 


8b.  OFFICE  SYMBOL 
(If  applicable) 


9.  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 


8c  ADDRESS  (City.  State,  and  ZIP  Code) 


10.  SOURCE  OF  FUNDING  NUMBERS 


PROGRAM 

PROJECT 

TASK 

WORK  UNIT 

ELEMENT  NO. 

NO. 

NO 

ACCESSION  NO. 

1 1 .  TITLE  (Include  Security  Classification) 

Software  Quality  Tools 


12.  PERSONAL  AUTKOR(S) 

Michael  D.  Stewart 


13a.  TYPE  OF  REPORT 

Final 


13b.  TIME  COVERED 
FROM _ TO 


14. 


D^E^F^R^^RT  {Year,  Month.  Day) 


15.  PAi 


01^0 


UNT 


16.  SUPPLEMENTARY  NOTATION 

U' 


r 

''  \ 


[^fZ.  COSATI  CODES  | 

FIELD 

GROUP 

SUB-GROUP 

18.  Subject  terms  (continue  on  reverse  if  necessary  and  identify  by  block  number) 

A/'  f"'- '  L.  •:.!  ■'  ■  ■  <0  i\£  (^\ 0  /V'  * I 


19.  ABSTRACT  {Continue  on  reverse  if  necessary  and  identify  by  block  number) 

Software  quality  tools  were  established  as  a  MATE  requirement  by  ^FfiC/AFLC  800-23. 

The  delivered  product  will  only  work  on  version  3.  of  MCSS.  These  tol>3^s  are  highly  labor 
intensive  due  to  the  large  number  of  databases  which  must  be  manually  in^THt^or  each 
test  program.  -There- ±s -to  iirovGmeTrt"-ett  MATE-SPO  to  update- these- teeis^  The^rtAG  iiSC 
recommends  that  useful,  supportable,  and  maintainable  tools  be  developed  or  purchased^^ 
for  use  with  current  MATE  software,  ..  ^ \ C  ^ 


€■ 


?0  DICTRIRI.iTION /AVAILABILITY  OF  ABSTRACT 

□  unclassified/unlimited  B  same  AS  RPT.  □  OTIC  USERS 


21.  ABSTRACT  SECURITY  CLASSIFICATION 


22a.  NAME  OF  RESPONSIBLE  INDIVIDUAL 

LEROY  HUDSON 


22b  TELEPHONE  (/nc/oc/e  Area  Code) 

912-926-1501 


22c.  OFFICE  SYMBOL 
MAITBD 


00  Form  1473,  JUN  86 


Previous  editions  are  obsolete. 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 

UNCLASSIFIED 


Report  MAG  87-009-01 


1 


% 


Software  Quality  Tools 


Michael  D.  Stewart 
Software  Production  Branch 
WR-ALC/MAITBA 

Warner  Robins  AFB,  Ga.  31098-5148 


04  May  1988 


Approved  for  public  release. 
Distribution  unlimited. 


Final  Report 


Prepared  for 

MATE  Applications  Group 

WR-ALC/MAIT 

Robins  AFB  31098-5148 


Accession  For 

NTIS  GRA4I 

DTIC  TAB 

Unannounced 
Justification _ 

□ 

By 

Distribution/ 


Avallnblllty  Codes 
Avari  and/or 
Special 


88  11 


2  8  0  ^ 


APPROVAL  SEDBET 


Report  ID:  MAG  87-009-01 


Title:  Software  Quality  Tools 


Author(s) 


Standing  i  >  r 
Committee  W  1 
Chairperson: 

P.' 

Vvvx; 

\A  . 

1 

i 


Preface 


This  report  was  written  by  members  of  the  MATE  Applications  Group  (MAG) 
to  assist  the  Modular  Automatic  Test  Epuipment  (MATE)  program. 

MATE  is  an  Acquisition  Management  program  established  by  AFSC/AFLC 
regulation  800-23. 

The  MAG  was  established  in  recognition  of  the  need  for  Air  Force  users 
to  Influence  the  application  and  future  of  MATE^  This  need  was  identified 
during  the  AFLC  MATE  Conference  held  at  Wrlght^Patterson  AFB  on  31  March 
1987 .  .  .  _ _ _ 

^'^The  owaral^^bjective  of  the  MAG  is  to  support  and  improve  the  MATE 
concept  and  programs.  This  will  be  accomplished  by  assessing  the  needs  of 
the  maintenance  community  and  establishing  a  means  of  communicating  those 
needs  from  the  operating/user  (maintenance)  organizations  to  the 
managing/acquisition  organizations. 

This  report  must  be  considered  ia  the  context  of  the  MATE  program. 
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1.0  ISSUE: 


Assuring  Test  Program  Set  Software  quality  in  the  MATE  environment. 

2.0  FACTORS  BEARING  ON  THE  ISSUE: 

2 . 1  Background : 

AFSC/AFLC  800-23  addresses  the  need  for  software  quality  with  the 
Automated  Quality  Assurance  Tools.  These  tools  were  delivered  only  last 
year.  A  detailed  assessment  was  done  by  the  MAG  and  is  included  as 
Appendices  A  through  E. 

3.0  CRITERIA: 

3.1  QA  Software  Tools  must  provide  a  structured  environment  to  assure  that 
TPSs  developed  are  capable,  supportable  and  maintainable. 

3.2  QA  Software  Tools  must  have  minimum  impact  on  MATE  hardware 
resources. 

3.3  Benefits  of  the  QA  Software  Tools  must  be  realized  economically. 

3.4  QA  Software  Tools  must  be  "User  Friendly". 

3.5  QA  tools  must  provide  useful  information  about  the  test  program's 
ability  to  test  the  UUT. 

4.0  DEFINITIONS 

Quality  Assurance  -  Quality  Assurance  controls  the  development  process 
to  insure  a  product  will  be  built  correctly. 

Quality  Control  -  Quality  Control  is  an  effort,  after  a  product  is 
complete,  to  insure  that  it  meets  quality  standards. 


5.0  DISCUSSION: 

5.1  MATE  Guides  place  major  emphasis  on  the  analysis  of  ATLAS  programs 
after  they  have  been  developed  (Quality  Control).  More  emphasis  is  needed 
in  the  area  of  TPS  development  (Quality  Assurance). 

The  Air  Force  as  a  whole  is  moving  from  Quality  Control  to  Quality 
Assurance.  The  main  reason  for  this  thrust  is  the  major  savings  possible  by 
assuring  something  is  done  right  the  first  time. 
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5.2  Some  possible  Quality  Assurance  Tools  are: 

1.  ATLAS  programmers  need  a  language  sensitive  editor  which  will 
ensure  that  the  syntax  is  correct. 

2.  Utility  to  re-number  the  ATLAS  statements  when  tests  are  changed  or 
added. 

3.  Utilities  to  automatically  extract  management  data  from  the  ATLAS 

code. 


5.3  All  Quality  Assurance  tools  must  be  hosted  off-line;  this  will  result 
in  better  programs  produced  at  a  lower  cost  in  less  time. 

5.4  Quality  Control  tools  are  also  needed  for  use  by  the  government  to 
assure  the  quality  of  TPSs  delivered. 

6.0  ALTERNATIVES: 

6.1  There  exists  in  the  commercial  arena  several  software  development 
packages  which  are  designed  to  aid  in  the  development  and  production 
of  test  program  sets.  Some  of  these  are  currently  being  used  by  the 
Military  and  by  defense  contractors  to  produce  ATLAS  programs. 

Others  are  being  developed  for  future  applications. 

EXAMPLES: 

1.  TYX  Corp.  markets  a  software  development  package  called  PAWS. 
This  package  consists  of  approximately  30  individual  application  programs 
that  perform  the  functions  of  ATLAS  Subset  and  Test  Station  Database 
Processors,  ATLAS  Translation  Processors,  Test  Executives,  Editors, 
Documentation  Tools,  Management  and  QA  Tools  and  a  Menu  Environment. 

2.  LEXICO  also  markets  off-the-shelf  software  development  packages 
to  support  a  variety  of  testers  currently  in  use  by  the  DoD. 
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6.2  Acquire  or  develop  Quality  Assurance  tools  that  could  be  provided  GFE 
to  all  TPS  developers.  The  advantage  here  is  a  standard  process  could  be 
developed  for  all  TPS  development.  If  commercial  products  are  used  it  is 
impossible  to  standardize  due  to  competition  laws.  It  potentially  is  the 
less  expensive  option,  if  good  tools  are  developed! 

7.0  CONCLUSIONS: 

1)  The  existing  MATE  Automated  Quality  Assurance  Tools  are 
impractical. 

2)  Commercial  products  exist  that  will  do  most  of  the  job. 

3)  GFE  Quality  Assurance  tools  could  be  developed. 

A)  The  government  should  develop  its  own  Quality  Control  tools. 

8.0  RECOMMENDATIONS: 

8.1  Do  not  use  the  current  version  of  the  MATE  Software  Quality  Assurance 
Tools. 

8.2  Encourage  the  use  of  commercial  Quality  Assurance  tools  while  at  the 
same  time  pursuing  the  development  of  some  MATE  Quality  Assurance  tools. 

8.3  Develop  practical  MATE  Quality  Control  tools.  These  must  be  government 
controlled  to  maintain  uniformity  and  contractor  integrity. 

8.4  Require  that  all  QA  and  QC  Tools  developed  can  be  hosted  and  used  on  a 
multi-user,  off-line  host. 
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APPENDIX  A 

PRELIMINARY  REPORT  to  the 
MATE  APPLICATIONS  GROUP 
LOGISTICS  STANDING  COMMITTEE 


1.  ISSUE: 


Evaluation  of  QA  Software  Tools  as  delivered  to  SA-ALC. 

2.  FACTORS  BEARING  ON  THE  ISSUE: 

2.1  Background:  Four  reference  documents  were  used  for  this  report. 

2.1.1  MATE  Application  Group  Initiative  Traveler  87-009  was  requested 
by  WR-ALC/MAITC. 

2.1.2  MATE  Guide  5,  vol.  3,  part  7,  sections  8  through  14  provide  a 
description  of  the  QA  Software  Tools. 

2.1.3  MATE  Guide  5,  Volume  3,  Part  11  provides  the  requirements  for 
the  test  software  design. 

2.1.4  T.O.  CFE  41  provides  a  preliminary  users 
manual  for  the  QA  Software  Tools. 

2.2  Requirements:  Test  Program  Set  (TPS)  QA  Software  Tools  were 
designed  to  optimize  the  efficiency  and  applicability  of  a  MATE  ATLAS 
program,  analyze  fault  isolation  Ambiguity  groupings,  associated  Flow 
Rates  Ratios  and  Weighted  Reliability  Ratios,  and  report  Test  Accuracy 
Ratios.  They  were  designed  also  to  compare  the  TPS  test  limits  to  the 
UUT  design  limits  as  set  forth  in  the  Test  Requirements  Document  (TRD) 
for  the  associated  UUT.  They  were  designed  to  support  the  quality 
assurance  function  in  the  areas  of  inspection,  analysis,  audit,  and 
demonstration  for  the  validation  and  verification  of  the  TPS. 

2.3  CRITERIA: 

1.  The  QA  Software  Tools  must  provide  useful  information 
about  the  test  program's  ability  to  test  the  UUT. 

2.  The  QA  Software  Tools  should  be  economically  advantageous. 

3.  The  QA  Software  Tools  should  be  easy  to  use. 

4.  The  QA  Software  Tools  should  have  minimum  impact  on  the 

MATE  test  station  efficiency. 

2.4  Findings;  Four  of  the  tools  have  been  released  by  ASD  to  SA-ALC 
MATE  Operations  Center: 


MATE  ATLAS  Test  Efficiency  and  Applicability  program  (TEA) 

MATE  ATLAS  Ambiguity  Group  Distribution  program  (AGD) 

MATE  ATLAS  Test  Accuracy  Ratio  Evaluation  program  (TARE) 

MATE  ATLAS  Limit  Comparison  vs.  Code  program  (LCSC) 
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2.5  Facts: 


2.5.1  The  QA  Software  Tools  require  a  MIL-STD  1750A  computer  with  at 
least  64k  word  available  memory,  a  disk  drive,  and  a  MATE 
keyboard/display  terminal,  a  MATE  line  printer,  and  a  MATE  tape  drive. 

The  operation  is  facilitated  by  the  MATE  Operating  System  (MOS)  and 
the  MATE  On-line  Editor  (MOLE). 

2.5.2  The  QA  Software  Tools  were  designed  to  analyze  ATLAS  test 
programs.  This  requires  recognition  of  specific  ATLAS  keywords.  A 
utility  called  BUILD  is  the  process  which  facilitates  this 
recognition.  Prior  to  execution,  BUILD  requires  the  development  of  a 
keyword  file.  The  keyword  file  contains  an  alphabetical  list  of  ATLAS 
key  words  in  the  following  classes:  Verb,  Noun,  Modifier,  Dimension 
and  Modifier  Descriptor.  The  format  of  the  keyword  file  is 
illustrated  in  Appendix  1. 

2.5.3  The  instrument  data  base  to  be  used  for  the  operation  of  the 
TARE  and  LCSC  QA  Software  Tools  is  test  system  dependent,  and 
therefore  needs  to  be  generated  once  for  that  test  system.  It  may 
then  be  used  on  all  test  programs  that  are  developed  for  a  particular 
application.  A  process  called  SBUILD  is  used  to  accomplish  this. 

Prior  to  the  execution  of  SBUILD,  a  data  base  file  called  the  System 
Allocation  Data  Base  file  (sadb.in)  must  be  generated.  Each 
instrument  in  the  test  station  is  described  in  detail  using  ATLAS  noun  and 
noun  modifier,  ranges,  tolerances,  and  dimensions  of  the  modifier.  The 
format  for  the  SADB  file  is  illustrated  in  Appendix  1. 

2.5.4  Before  the  QA  Software  Tools  can  be  executed,  there  are  at 
least  five  database  files  which  must  be  manually  created  according  to 
specific  format  requirements  for  each  tool.  The  procedures  within 
each  tool  act  on  these  databases  and  perform  the  reformatting  of  the 
data  into  binary  output  files.  Examples  of  the  database  formats  are 
included  in  Appendix  1.  Appendix  4  lists  the  QA  Tools  and  the 

input  files  required  for  each. 

2.5.5  There  are  report  and  device  options  for  each  tool  that  may  be 
used  in  specified  combinations.  Each  option  will  produce  a  different 
report,  or  route  the  output  file  to  a  different  device.  Appendix  2 
contains  a  list  of  the  report  and  device  options. 

2.5.6  Certain  programming  limitations  exist  which  must  be  considered 
prior  to  the  execution  of  the  QA  Software  Tools.  Some  limitations  are 
global  in  nature  while  others  are  unique  to  a  particular  tool.  A 
complete  list  of  the  limitations  is  in  attachment  3. 

2.5.7  The  MATE  ATLAS  test  program  must  be  structured  in  accordance 
with  the  test  software  design  guide  MATE  Guide  5,  Volume  3,  Part  11 
with  special  attention  given  to  the  structure  of  QA  comments  and 
output  message  statements. 
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3.0  DEFINITIONS: 


3.1  The  TEA  is  designed  to  examine  the  efficiency  and  applicability 
of  a  MATE  ATLAS  test  program.  The  execution  of  the  TEA  requires  the 
development  of  a  database  file  called  the  Reliability  Data  Base 
(RDB).  The  RDB  file  contains  data  that  is  specific  to  the  UUT  to  be 
tested  by  the  ATLAS  Test  Program.  The  data  describes  the  UUT  and  the 
RUs  contained  within  the  UUT.  The  RDB  is  developed  by  a  manual 
process  consisting  of  a  line-by-line  examination  of  the  ATLAS  Test 
Program  and  UUT  documentation  extracting  Statement  numbers,  Number  of 
Pins,  Pin  Identifier  Names,  Number  of  Replaceable  Units  on  the  UUT, 
Replaceable  Unit  Identifier  Name,  Failure  Rates  of  RUs,  MTBF  of  RUs, 
Number  of  Failure  Modes,  Failure  Mode  Identification  ("How-malfunction 
Code"),  Failure  Rate  of  Failure  Mode,  and  MTBF  of  Failure  Mode.  The 
TEA  generates  an  output  file  called  "TEA. OUT".  The  contents  of 

TEA. OUT  is  dependent  upon  the  report  option  selected  when  the  TEA  is 
invoked. 

3.2  The  AGD  program  scans  the  MATE  ATLAS  Test  program  for  Remove  and 
Replace  (R/R)  directives  to  determine  ambiguity  group  size  within  the 
test  program  and  equates  those  figures  to  an  acceptable  predetermined 
group  size.  The  AGD  requires  the  development  of  two  databases  prior  to 
execution,  the  Reliability  Data  Base  (RDB),  and  the  Ambiguity  Standard 
Data  Base  (ASDB).  The  RDB  file  structure  is  identical  to  that 
required  by  the  TEA.  The  ASDB  input  file  contains  data  that  describes 
the  UUTs  Ambiguity  Group  limits.  The  limits  include  the  Ambiguity 
Group  Size,  acceptable  Weighted  Reliability  Ratio  (VRR),  and 
acceptable  Flow  Rate  Ratio  (FRR).  These  elements  are  incorporated 
into  the  ASDB  binary  file  via  the  procedure  ASDBBLD.  The  AGD 
generates  an  output  file  called  AGD. OUT.  The  contents  of  AGD. OUT  is 
dependent  upon  report  and  output  device  options  selected  when  the  AGD 
is  invoked. 

3.3  The  TARE  program  is  designed  to  accept  and  scan  a  MATE  ATLAS 
source  code  test  procedure  to  determine  if  sufficient  Test  Accuracy 
Ratios  (TARs)  are  utilized  to  ensure  a  reliable  test  of  the  UUT.  The 
TARE  requires  the  development  of  two  database  files:  the  System 
Allocation  Data  Base  file  (SADB)  and  the  Source  Data  Base  file  (SDB). 
The  SADB  file  is  also  used  in  the  SBUILD  utility.  The  SDB  contains 
data  specific  to  UUT  pins.  The  data  describes  each  pin  by  the  ATLAS 
noun  and  noun  modifier  characteristics.  Each  modifier  description 
contains  the  ranges,  tolerances,  and  dimensions  of  the  modifier.  The 
report  and  Device  options  selected  when  the  TARE  is  invoked  determine 
the  contents  of  the  output  file  TARE. OUT. 

3.4  The  LCSC  program  is  designed  to  determine  if  the  MATE  ATLAS  test 
program  limits  are  in  accordance  with  those  specified  in  the  UUT  Test 
Requirements  Document  (TRD) .  The  LCSC  program  analyzes  the 
requirements,  procedures  and  programs  to  determine  whether  the 
stimulus  and  measurement  limits  of  the  coded  MATE  ATLAS  program  are  in 
agreement  or  accordance  with  the  design  limits  of  the  UUT.  This 
analysis  will  determine  if  the  programmed  signals  are  within  allowable 
ranges  to  provide  proper  stimulus  to  assure  that  measurements  are  such 


that  bad  UUTs  will  be  rejected  and  that  good  UUTs  will  be  accepted. 

The  Inputs  to  the  LCSC  are  Identical  to  those  of  the  TARE  program. 

Output  is  controlled  by  the  output  and  device  option  selected  by  the 
user  when  the  LCSC  is  invoked. 

4.0  DISCUSSION; 

4.1  Each  tool  has  a  variety  of  output  options  available  to  the 
user,  however,  the  option  must  be  selected  when  the  QA  Software  Tool 

is  first  invoked.  When  additional  data  is  desired  from  the  particular  tool 
being  utilized,  the  tool  must  be  Invoked  again.  The  tools  would 
be  more  efficient  with  o’^tput  options  menu  driven, 
modules. 

4.2  The  QA  Software  Tools  require  that  a  number  of  databases  be 
developed  in  order  for  them  to  function.  They  are  hampered  by  the 
lack  of  programming  aids  in  the  generation  of  the  databases.  This  is  a 
serious  shortcoming  of  the  tools.  There  are  at  least  five  files 
which  must  be  manually  generated.  With  the  exception  of  the  System 
Allocation  Data  Base  (SADB)  used  with  the  TARE  and  LCSC  Tools,  all 
the  database  files  must  be  generated  for  each  TPS.  Manual  generation 
of  these  files  adds  many  hours  to  the  development  time  for  TPSs  and 
makes  them  subject  to  errors.  MATE  documentation  does  not  assign  the 
responsibility  for  the  writing  of  these  files  (i.e.  Is  it  the 
responsibility  of  the  TPS  developer,  the  Quality  Branch  or  the  MM 
organization  to  see  that  the  database  files  are  available  and 
accurate? ) , 

4.3  The  QA  Software  Tools  require  a  1750A  computer  host  for  their 
operation.  Having  the  tools  hosted  on  the  1750A  results  in  increased 
loading  of  already  critically  short  resources.  Most  of  the  editing  of 
ATLAS  code  and  compiling  of  ATLAS  programs  is  being  done  on  an  off-line 
system.  Putting  the  QA  Software  Tools  on  an  off-line  host  would 
provide  availability  to  many  users  simultaneously  and  relieve  the 
loading  of  MATE  testers.  On  11  June  1986  WR-ALC/MAIT  submitted  a  GIF 
suggesting  this  be  adopted.  So  far  there  has  been  no  response  to  the 
GIF. 


4.4  Limitations  of  the  QA  Software  Tools  consist  mainly  of 
restrictions  placed  on  the  amount  of  data  the  QA  Software  Tools  are 
capable  of  including  in  the  analysis.  Examples  include  the  number  of 
DEFINE,  MESSAGE  statements,  number  of  RUs  per  ATLAS  statement,  length 
of  character  strings,  etc.  These  restrictions  come  into  play  when 
developing  TPSs  that  are  very  long.  This  is  the  time  the  QA  Software 
Tools  are  needed  the  most.  Short  programs  can  be  analyzed  manually 
with  efficiency. 
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5.0  CONCLUSIONS:  There  are  strong  arguments  against  the 
implementation  of  the  QA  Software  Tools  on  the  MATE  Test  stations. 


5.1  The  QA  Software  Tools  will  not  work  with  MATE  ATLAS  programs  that 
use  digital  stimulus  patterns  generated  by  HITS  and  other  non-ATLAS 
modules . 

5.2  The  QA  Software  Tools  are  too  labor  intensive. 

5.3  The  operation  of  the  tools  does  not  allow  flexibility  in 
selecting  the  desired  output  option. 

5.4  The  QA  Software  Tools  tie  up  production  test  equipment  that  is 
extremely  expensive  and  already  heavily  loaded. 

5.5  The  QA  Software  Tools  are  not  available  in  a  multi-user 
environment . 

6 . 0  RECOMMENDATIONS : 

6.1  It  is  recommended  that  the  requirement  for  QA  Software  Tools 
be  suspended  until  such  time  as  they  can  be  demonstrated  to  perform 
efficiently. 

6.2  It  is  recommended  that  industry  be  queried  as  to  the  availability 
of  automatic  QA  Software  Tools. 

6.3  It  is  recommended  that  the  QA  Software  Tools  be  reformatted  to 
run  on  an  off-line  operating  system. 


APPENDIX  B 

QA  SOFTWARE  TOOLS 
DATABASE  FILE  FORMATS 


KEY  WORD  INPUT  FILE  FORMAT 


Key  Word  Input  file  Description 

The  key  word  is  the  actual  ATLAS  key  word  as  it  appears  in  the  ATLAS 
test  program. 

The  class  is  denoted  as  follows: 


VERB . .V 

NOUN . N 

MODIFIER . M 

DIMENSION . D 

MODIFIER  DESCRIPTOR. .. .MD 

OTHER . 0 

PIN . P 


The  attributes  are  as  follows: 

VERB  NAME  ;  V  [ :  QA  TOOL  ,  QA  TOOL  (processing  the  verb)]  $ 

MODIFIER  NAME  :  M  [ :  MD  or  DIG]  $ 

Where  the  attribute  field  may  contain  a  modifier  descriptor  or  a 
digital  modifier. 

DIMENSION  NAME  :  D  [:  ]+/-]  (conversion  value)  (base  dimension)  ]  $ 
Each  line  in  the  Key  Word  file  ends  with  a  dollar  sign  ($). 


B-2 


EXAMPLE 


SAMPLE  KEY  WORD  INPUT  FILE 


AC  SIGNAL  :  N  :  $ 

BAUD  :  D  $ 

CLOCK-IN  :  P  $ 

DISPLAY  :  V  TEA,  AGD  $ 
FUEL-SUPPLY  :  M  :  DIG  $ 
GATE-START-SLOPE  :  M  :  DIG  $ 
MWPRDS/SEC  :  D  :  6  WORDS /SEC  $ 


SYSTEM  ALLOCATION  DATA  BASE  FORMAT 


SADB  Input  file  Description 

A.  The  first  line  of  the  file  is  the  database  name. 

B.  The  next  line  is  the  number  of  Instruments.  A  number  of  blocks, 
equal  to  the  number  of  instruments  follows.  Each  block  describes  the 
Instrument  and  its  attributes.  Each  block  must  be  preceded  by  a  line 
consisting  of  only  a  dollar  sign  ($). 

1.  The  first  line  of  the  block  is  the  instrument  name. 

2.  The  next  line  of  the  block  is  the  system  designator.  This 
describes  the  instrument  type  (e.g.,  sensor,  source,  load). 

3.  The  next  line  contains  the  number  of  nouns.  A  number  of 
blocks,  equal  to  the  number  of  nouns  follows.  Each  block  describes 
noun  modifiers  and  other  data  associated  with  the  noun. 

a.  The  first  line  contains  the  number  of  noun  modifiers 
associated  with  the  noun.  A  number  of  blocks,  equal  to  the  number  of 
modifiers  follows.  Each  block  describes  the  attributes  of  the 
modifier. 

I.  The  first  line  contains  the  modifier  name.  If  the 

name  is  enclosed  in  parentheses,  it  denotes  a  measured  characteristic. 

II.  The  next  line  contains  the  system  Inaccuracy.  This 

value  must  be  expressed  as  a  real  number  (no  scientific  notation).  If  pc 

follows  the  value,  the  system  inaccuracy  is  taken  to  be  a 

percentage. 

iii.  The  next  line  contains  the  dimension.  This  is  the 

type  of  units  that  the  range  and  tolerance  values  are  expressed  in.  A  null 
may  be  input. 

iv.  The  next  two  lines  are  for  the  range  values.  The 
first  line  is  the  the  upper  limit  (UL)  and  the  second  line  is  the 
lower  limit  (LL).  Both  values  must  be  expressed  as  real  numbers. 

V.  The  next  two  lines  are  for  the  tolerance  values.  The 
first  line  is  the  upper  limit  (UL)  and  the  second  line  is  the  lower 
limit  (LL).  Both  tolerance  values  must  be  expressed  as  real  numbers.  If  pc 
follows  the  value,  the  tolerance  is  taken  to  be  a  percentage. 

b.  The  last  line  of  the  file  contains  only  a  dollar  sign  ($). 
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SADB  EXAMPLE 


Database  Name 


Number  ofinstruments 


$ 


I 


Instrument  Name 


System  Designator 


Number  of  Nouns 


Noun 


Number  of  Modifiers 


Modifier 


System  Inaccuracy 


Dimension 


Range  -  Upper  Limit 


Range  -  Lower  Limit 


Tolerance  -  Upper  Limit 


Tolerance  -  Lower  Limit 
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SAMPLE  SYSTEM  ALLOCATION  DATA  BASE  (SADB)  FILE 


qasadbl . sadb 
1 

$ 

f  tim 
sensor 

1 

ac  signal 
5 

(freq) 

1  pc 
hz 

200e6 

0 

2  pc 
-2  pc 

voltage 

2  pc 

V 

50 

-50 

1  pc 
-1  pc 

voltage-p 

2  pc 

V 

50 

-50 

1  pc 
-1  pc 

voltage-pp 

2  pc 

V 

100 

0 

1  pc 
-1  pc 

test-equip-imp 
1  pc 

ohm 

50 

50 

0 

0 


*  data  base  name  mate  qa  tool  -  tare  and  Icsc 

*  no.  instruments  * 

*  instrument  name  * 

*  system  designator  * 

*  no.  nouns  * 

*  noun  * 

*  no.  modifiers  * 

*  modifier  * 

*  system  inaccuracy  * 

•*'  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  modifier  * 

*  system  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  modifier  * 

*  system  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  modifier  * 

*  system  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  modifier  * 

*  system  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 
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RELIABILITY  DATA  BASE  FILE  FORMAT 


**  DATABASE  FILES  ARE  ASCII  FILES  ** 

RDB  Input  File  Description 
LINE  ONE  is  the  DATABASE  NAME. 

LINES  TWO  and  THREE  are  for  STATEMENT  NUMBERS  in  the  ATLAS  program, 
the  purpose  is  to  exclude  a  block  of  code  from  analysis. 

LINE  FOUR  will  contain  the  NUMBER  OF  UUT  PINS.  A  number  of  lines 
equal  to  the  number  of  pins  will  follow  with  each  containing  the  pin 
identifier  name. 

The  next  line  will  contain  the  total  number  of  RUs.  A  number  of 
blocks  equal  to  the  number  of  RUs  will  follow  with  each  block  pre¬ 
ceded  by  a  line  containing  only  a  $.  (Either  the  FM  or  the  FM  MTBF 

may  be  replaced  with  the  word  'null'  but  not  both.  These  three-line 
groups  are  repeated  until  all  FMs  are  described). 

The  last  line  of  the  file  contains  only  a  $. 
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RDB  EXAMPLE 


Database  Name 


Exclude  From  Statement  Number 


Exclude  To  Statement  Number 


Number  of  Pins 


$ 


Pin  Identifier  Name 


Pin  Identifier  Name 


Pin  Identifier  Name 


Pin  Identifier  Name 


Pin  Identifier  Name 


etc. 


Number  of  Replaceable  Units  (RUs) 


$ 


RU  Name 


Failure  Rate  (FR) 


MTBF  (Mean  Time  Between  Failure) 


FMs  (Failure  Modes) 


Failure  Mode  ID  (how  malcode) 


FM  Failure  Rate 


FM  MTBF 


$ 
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SAMPLE  RELIABILITY  DATA  BASE  (RDB)  FILE 


qardbl . rdb 
050000 
099999 
2 

jl-a 

Pt 

2 

$ 

1 

1000000 

1 

4 

450 

null 

8 

615 

null 

6 

626 

null 

5 

748 

null 

2 

$ 

alO 

100000 

null 

5 

169 

666666 

null 

450 

null 

2 

615 

725000 

null 

saO 

null 

7.5 

ssl 

null 

8.2 


*  data  base  name  mate  qa  tool  -  agd  and  tea 

*  exclude  from  * 

*  exclude  to  * 

*  no.  pins  * 

*  pin  id  * 

*  pin  id  * 

*  no.  replaceable  units  * 

*  ru  id  * 

*  failure  rate  * 

*  mtbf  * 

*  no.  failure  modes  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  ru  id  * 

*  failure  rate  * 

*  mtbf  * 

*  no.  failure  modes  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  failure  mode  id 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 

*  failure  mode  id  * 

*  fm  failure  rate  * 

*  fm  mtbf  * 
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AMBIGUITY  STANDARD  DATA  BASE  FORMAT 


The  first  line  is  the  database  name.  The  name  should  include  .ASDB  for 
identification  purposes. 

The  next  line  contains  the  maximum  ambiguity  group  size.  This  is  the 
maximum  replaceable  units  that  may  be  in  any  ambiguity  group. 

The  rest  of  the  database  consists  of  3-line  blocks,  one  for  each 
ambiguity  group.  Each  block  is  preceded  by  a  $. 

The  first  line  of  the  block  is  the  number  of  replaceable  units  in  the 
ambiguity  group.  The  next  line  is  the  Weighted  Reliability  Ratio. 

The  next  line  is  the  Flow  Rate  Ratio. 

The  last  line  of  the  file  contains  only  a  $. 

AMBIGUITY  STANDARD  DATA  BASE  FORMAT 


Database  Name 


Maximum  Ambiguity  Group  Size. 


$ 


ambiguity  group  size 


acceptable  WRR 


acceptable  FRR 


$ 


SAMPLE  AMBIGUITY  STANDARD  DATA  BASE  (ASDB)  FILE 


qaasdbl.asdb 

3 

$ 

1 

.70 

.90 

$ 

2 

.20 

.06 

$ 

3 

.10 

.04 

$ 


*  data  base  name  mate  qa  tool  -  agd  * 

*  max  ags  * 

*  ags=l  * 

*  wrr  * 

*  frr  * 

*  ags =2  * 

*  wrr  * 

*  frr  * 

*  ags=3  * 

*  wrr  * 

*  frr  * 
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SOURCE  DATA  BASE  FORMAT 


SDB  Input  file  Description 

A.  The  first  line  of  the  file  is  the  database  name.  The  name  should 
include  .SDB  for  Identification  purposes. 

B.  The  next  two  lines  are  for  statement  numbers  in  the  ATLAS  program. 
These  must  be  six  digit  numbers  or  the  word  'null'.  The  purpose  of 
these  elements  is  to  exclude  a  block  of  code  from  the  analysis. 

C.  The  next  line  is  the  number  of  pins.  A  number  of  blocks,  equal  to 
the  number  of  pins  follows.  Ea.'h  block  describes  the  pin  and  its 
attributes.  Each  block  must  be  preceded  by  a  line  consisting  of  only  a 
dollar  sign  ($). 

1.  The  first  line  of  the  block  is  the  pin  name. 

2.  The  next  line  of  the  block  is  the  pin  designator.  This 
describes  the  pin  type  (e.g.,  in/out,  in,  out,  none). 

3.  The  next  line  contains  the  number  of  nouns.  A  number  of 
blocks,  equal  to  the  number  of  nouns  follows.  Each  block  describes 
noun  modifiers  and  other  data  associated  with  the  noun. 

a.  The  first  line  contains  the  number  of  noun  modifiers 
associated  with  the  noun.  A  number  of  blocks,  equal  to  the  number  of 
modifiers  follows.  Each  block  describes  the  attributes  of  the 
modifier. 

1.  The  first  line  contains  the  modifier  name.  If  the 
name  is  enclosed  in  parentheses,  it  denotes  a  measured  characteristic. 

ii.  The  next  line  contains  the  ITA  inaccuracy.  This 

value  must  be  expressed  as  a  real  number  (no  scientific  notation).  If 
pc  follows  the  value,  the  ITA  inaccuracy  is  taken  to  be  a 
percentage. 

iii.  The  next  line  contains  the  dimension.  This  is  the 
type  of  units  that  the  range  and  tolerance  values  are  expressed.  A 
null  may  be  input. 

iv.  The  next  two  lines  are  for  the  range  values.  The 
first  line  is  the  the  upper  limit  (UL)  and  the  second  line  is  the 
lower  limit  (LL).  Both  values  must  be  expressed  as  real  numbers  or 
NULL.  If  NULL  is  used,  the  nominal  range  value  must  be  a  non-NULL 
value.  INFINITY  may  be  input  for  either  upper  or  lower  limit,  but  not 
for  both. 


V.  The  next  two  lines  are  for  the  tolerance  values.  The 
first  line  is  the  upper  limit  (UL)  and  the  second  line  is  the  lower 
limit  (LL).  Both  tolerance  values  must  be  expressed  as  real  numbers. 
If  pc  follows  the  value,  the  tolerance  is  taken  to  be  a  percentage. 
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vi.  The  last  line  of  the  block  is  the  nominal  range  value. 

In  come  cases,  a  nominal  range  of  0  is  possible.  If  NULL  is  input  for 
the  nominal  range,  the  upper  and  lower  limits  must  be  non-NULL. 

b.  The  last  line  of  the  file  contains  only  a  dollar  sign  ($). 

SDB  EXAMPLE 


Database  Name 


Exclude  From  Statement  Number 


Exclude  To  Statement  Number 


Number  of  Pins 


$ 


Pin  Identifier  Name 


Pin  Designator 


Number  of  Nouns 


Noun 


Number  of  Modifiers 


Modifier 


ITA  Inaccuracy 


Dimension 


Range  -  Upper  Limit 


Range  -  Lower  Limit 


Tolerance  -  Upper  Limit 


Tolerance  -  Lover  Limit 


Nominal  -  Range 


$ 
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SAMPLE  SOURCE  DATA  BASE  (SDB)  INPUT  FILE 


qfsdbl.sdb 

050000 

099999 

1 

$ 

jl-a 

in 

2 

dc  signal 
2 

voltage 

2  pc 

V 

null 
null 
10  pc 
-10  pc 
28 

current-lmt 

1  pc 
a 

null 
null 
20  pc 
-20  Pc 

3 

dc  signal 

2 

voltage 
2  pc 

V 

null 
null 
10  pc 
-10  pc 
5 

current-lmt 
1  pc 
ma 
null 
null 
20  pc 
-20  pc. 

1 

$ 


*  data  base  name  mate  qa  tool  -  tare  and  Icsc 

*  exclude  from  * 

*  exclude  to  * 

*  no.  pins  * 

*  pin  id  * 

*  pin  designator  * 

*  no.  nouns  * 

*  noun  * 

*  no  modifiers  * 

*  modifier  * 

*  ita  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  range  -  nom  * 

*  modifier  * 

*  its  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  range  -  nom  * 

*  noun  * 

*  no.  modifiers  * 

*  modifier  * 

*  ita  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  range  -  nom  * 

*  modifier  * 

*  ita  inaccuracy  * 

*  dimension  * 

*  range  -  ul  * 

*  range  -  11  * 

*  tol  -  ul  * 

*  tol  -  11  * 

*  range  -  nom  * 
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APPENDIX  C 
REPORT  OPTIONS 


TEA  Report  Options 


r  -  "Test  Program  Applicability  Ratio" 
u  -  "UUT  Replaceable  Units" 
f  -  "Failure  Mode  Testing" 
o  -  "Pin  Testing" 
a  -  Includes  Options  r,u,f,o. 
e  -  "Efficiency  Measurement" 

1  -  "Ordered  Reliability" 

h  -  Help  option  -  displays  all  available  options 
Device  Options 

c  -  display  report(s)  at  CRT  and  disk 
d  -  display  report(s)  at  printer  and  disk 
s  -  send  report(s)  to  disk  only 


AGD  Report  Options 

a  -  "R/R  and  Their  Test  Numbers" 
r  -  "R/R  and  Their  RUs" 
t  -  "Total  R/R" 
g  -  "MAX  Group  Size  Exceeded" 
f  -  "Flow  Rate  Ratio" 

1  -  "Detailed  Display" 

X  -  Includes  all  the  above  options 
h  -  Help  option  -  displays  all  available  options 

Device  Options 

c  -  Display  report(s)  at  the  CRT  and  disk 
d  -  Display  report(s)  at  the  line  printer  and  disk 
s  -  Send  report(s)  to  disk  only 


TARE  Report  Options 
t  -  "Detailed  Display" 

e  -  "Diagnostic  Display"  for  statements  whose  TAR  falls  below 
user  input  TAR  limit 
i  -  "Interleaved  Display" 

h  -  Help  option  -  displays  all  available  options 
Device  Options 

c  -  displays  report(s)  at  CRT  and  disk, 
d  -  displays  report(s)  at  line  printer  and  disk, 
s  -  sends  report(s)  to  the  disk  only. 
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LCSC  Report  Options 


t  -  "Detailed  Display" 

e  -  "Diagnostic  Display"  for  the  signal  statements  whose 
tolerance  band  exceeds  input  limit, 
i  -  "Interleaved  Display" 

h  -  Help  option  -  displays  all  available  options 
Device  Options 

c  -  displays  report(s)  at  CRT  and  disk, 
d  -  displays  report(s)  at  line  printer  and  disk 
s  -  sends  report(s)  to  disk  only 
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APPENDIX  D 
LIMITATIONS 


PROGRAM  LIMITATIONS 


GLOBAL  LIMITATIONS 


ATLAS  IDENTIFIER  -  The  maximum  length  of  and  ATLAS  identifier  or 
variable  is  16  characters. 

File  names  -  The  maximum  length  of  a  file  name  is  14  characters. 

Path  names  -  The  maximum  length  of  a  1750  path  name  is  250  characters 

Maximum  AGS  -  The  largest  ambiguity  group  size  allowed  in  the  ASDB  or 
ATLAS  program  is  100. 

Buffer  Size  -  The  size  in  characters  of  the  GETCHR  input  buffer  is  50 

Conversion  Size  -  The  maximum  size  of  a  character  string  converted 
from  a  floating  point  or  integer  value  is  15  characters. 

Maximum  Number  of  ATLAS  procedures  -  The  maximum  number  of  procedures 
allowed  in  the  ATLAS  program  is  20. 

Maximum  Number  of  Pins  -  The  maximum  number  of  pins  per  statement 
allowed  in  the  ATLAS  program  is  32. 

Maximum  Number  of  Parameters  -  The  maximum  number  of  parameters  to  be 
passed  in  a  procedural  called  is  20. 

Connection  Fields  -  The  maximum  number  of  connection  fields  in  an 
ATLAS  statement  is  64. 

Maximum  Number  of  RUs  -  The  maximum  number  of  replacement  units  per 
statement  is  6. 

Maximum  Number  of  FMs  -  The  maximum  number  of  failure  modes  per 
ATLAS  statement  is  10. 

Maximum  Number  of  Defined  Messages  -  The  maximum  number  of  define 
messages  in  an  ATLAS  program  is  32. 

Maximum  Number  of  Message  Character  Variables  -  The  maximum  number  of 
message  character  variables  in  an  ATLAS  program  is  20. 

ATLAS  Keyword  Length  -  The  maximum  length  of  an  ATLAS  keyword  is  24 
characters. 
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TEA  LIMITATIONS 


FMs  -  The  maximum  number  of  failure  modes  that  appear  in  the  test 
program  and  do  not  appear  in  the  reliability  data  base  is  100. 


ACD  LIMITATIONS 

Worst  Case  R&R  for  and  AGS  -  The  maximum  number  of  equivalent  worst 
case  occurrences  allowed  for  and  Ambiguity  Group  is  50.  Worst  case  is 
the  R&R  Directive  with  the  worst  FR  from  an  Ambiguity  Group. 


TARE  LIMITATIONS 

Maximum  Number  of  Instruments  -  The  maximum  number  of  qualifying 
instruments  for  an  ATLAS  signal  statement  is  20. 

Maximum  Number  of  Modifiers  -  The  maximum  number  of  modifiers  for  an 
ATLAS  signal  statement  is  20. 

Maximum  Number  of  Nouns  -  the  maximum  number  of  qualifying  nouns  for 
an  ATLAS  signal  statement  is  20. 


LCSC  LIMITATIONS 

Maximum  Number  of  Instruments  -  The  maximum  number  of  qualifying 
instruments  for  an  ATLAS  signal  statement  is  20. 

Maximum  Number  of  Modifiers  -  The  maximum  number  of  modifiers  for  an 
ATLAS  signal  statement  is  20. 

Maximum  Number  of  Nouns  -  the  maximum  number  of  qualifying  nouns  for 
an  ATLAS  signal  statement  is  20. 
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MATE  QUALITY  ASSURANCE  TOOLS 
DATABASE  REQUIREMENTS 
AGD  OPERATION 


INPUT  FILES 

RDB  -  Reliability  Data  Base 
ASDB  -  AMBIGUITY  Standard  Data  Base 
OUTPUT  FILES 

RURDB.BIN 
AUXRDB.BIN 
AGD. OUT 


E-2 


MATE  QUALITY  ASSURANCE  TOOLS 
DATABASE  REQUIREMENTS 
TEA  OPERATION 


INPUT  FILES 

RDB  -  Reliability  Data  Base 

OUTPUT  FILES 

RURDB.BIN 
AUXRDB . BIN 
TEA. OUT 
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MATE  QUALITY  ASSURANCE  TOOLS 
DATABASE  REQUIREMENTS 
TARE  OPERATION  INPUT  FILES 


SADB.IN  -  System  Allocation  Data  Base 
SDB  -  Source  Data  Base 

OUTPUT  FILES 
SADB.DAT 
AUXSAD.DAT 
SDB. BIN 
AUXSDB.BIN 


1 
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MATE  QUALITY  ASSURANCE  TOOLS 
DATABASE  REQUIREMENTS 
LCSC  OPERATION 

INPUT  FILES 

SADB.IN  -  System  Allocation  Data  Base 
SDB  -  Source  Data  Base 
OUTPUT  FILES 

SADB.DAT 
AUXSAD.DAT 
SDB. BIN 
AUXSDB.BIN 
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